Создаем игры с нуля! 3 книги для старта в гейм-деве - Григорий Радовильский

документов, составляемых менеджерами и техническими специалистами (в основном это инструкции), над документацией игры работают гейм-дизайнеры. Системные дизайнеры трудятся над механиками, математики создают баланс и боевую систему, дизайнеры уровней – схемы уровней, сценаристы – сюжеты и квесты, контентщики корпят над персонажами и предметами. Игра проходит через гейм-дизайнеров от начала и до конца, от концепции до контента, окончание работы над которым свидетельствует об окончании процесса производства игры. В результате этого у гейм-дизайнеров образуются собственные пайплайны решения конкретных задач и работы над документацией в целом. И этот пайплайн оказывается в основе всей работы над игрой, просто потому что решение каких-то конкретных задач (создание графики, кода, уровней и предметов) находится внутри него: между утверждением финальной документации и проверкой реализации на соответствие ей.

Следующий пример касается разработки отдельной механики или игровой фичи, хотя мы уже видели, что, в общем, процесс разработки любого отдельного элемента похож на цикл разработки всей игры. Этот пример максимально подробный, но остается всего лишь примером, а реальный пайплайн работы над фичей может и будет зависеть от состава команды.

1. Подготовительный этап

• Запрос – идея фичи или игровой механики, состоящая из короткого описания и целей: улучшение игрового процесса или каких-то бизнес-показателей. Запрос может исходить практически от кого угодно: от руководства студии или даже от игроков.

• Создание концепции – более детальное описание того, как идея должна быть встроена в игру, каким образом будут достигнуты поставленные цели.

• Первое обсуждение – проверка идеи на соответствие концепции игры в целом и возможности ее реализации, а также выполнения поставленных задач.

• Финализация концепции – в соответствии с появившимися на предыдущем шаге сомнениями и новыми данными.

• Технический анализ – оценка идеи с точки зрения технических ограничений и возможного влияния на техническую архитектуру игры в целом. Его должны производить технические специалисты, а не дизайнеры.

• Финальная оценка – определение трудозатрат, рисков и ценности идеи для проекта.

В результате подготовительного этапа идея может быть пущена в производство как оформленная фича. В данном контексте фича означает не фишку игры, которую маркетологи будут предлагать игрокам, а комплексную задачу в рамках управления проектом – это производственный термин.

2. Производство

• Разработка дизайн-документации фичи – создание описания механики, персонажей, макетов и схем.

• Разбивка фичи на отдельные задачи (декомпозиция) – определение списка задач, которые необходимо выполнить для реализации фичи в полном объеме, и оценка времени на их выполнение.

В рамках одной фичи задачи могут делиться на взаимосвязанные логические блоки, для работы над которыми могут понадобиться очень разные навыки: арт, дизайн, программирование. В методике управления Agile эти блоки называются User Story (пользовательские истории, в данном случае это тоже производственный термин) и описывают буквально, что должен увидеть или иметь возможность сделать пользователь в результате окончания работы над этим блоком.

При создании блоков сама постановка задачи идет от лица пользователя: «как игрок (кто), я хочу управлять автомобилем (что), чтобы логично перемещаться по игровому миру (зачем)», а не от лица заказчика, коим в данном случае выступает дизайнер игры. Конечно, задачи могут ставиться и от лица дизайнера тоже: например, если необходимо разработать какой-то инструмент, облегчающий работу над игрой. «Как гейм-дизайнер, я хочу использовать удобную форму для создания новых предметов, чтобы не тратить на эту работу по 20 минут на предмет». Формулировка громоздкая, но позволяет сразу понять, что и для чего нужно сделать.

Пользовательская история не должна быть слишком большой по объему работы. Все разнообразие механик завладения какой-нибудь машиной в игровом мире, перемещения персонажа внутри нее и началом управления – это отдельные пользовательские истории, которые, собственно, и составляют комплекс фичи. Потом уже пользовательские истории делятся на отдельные задачи: создание анимации персонажа, садящегося в автомобиль, создание логики перемещения персонажа к водительской двери независимо от его изначального положения относительно машины, реакция неигровых персонажей на эти действия.

Отдельные задачи внутри пользовательской истории, конечно, могут составлять взаимозависимые блоки: когда работа дизайнеров уровней зависит от художников и сценаристов, что образует свой небольшой пайп-лайн. Этот пайплайн, выработанный на этапе вертикального среза, может значительно облегчить процесс анализа предстоящей работы и менеджмента задачи во время ее выполнения.

• Производство – собственно, выполнение задач, связанных с фичей.

• Проверка реализации и тестирование – работа над фичей может быть закончена, если заказчик (дизайнер) удостоверился в том, что она соответствует задумке, но начавшееся на этом этапе тестирование может не завершиться никогда. Соответственно, баги, связанные с несоответствием задумке, остаются внутри фичи и пользовательской истории, пока не будут исправлены, а баги, связанные с общей работоспособностью игры, уходят на более высокий уровень.

В результате этапа производства фича должна быть добавлена к проекту как готовая к релизу. Например, если наша игра уже запущена и мы занимаемся производством каких-то дополнительных механик, у нас будут отдельные производственные линии, сходящиеся в релизной версии игры, при том что сама релизная версия может обновляться со временем в результате исправления попавших в релиз багов. Соответственно, может быть необходима работа отдельного человека или даже целой группы специалистов, которые решат проблему объединения новой фичи с проектом. Частично помочь с этой задачей может правильное использование системы контроля версий. Но в любом случае игра потребует дополнительного тестирования уже релизной версии, так как добавление к развивающемуся релизу новой фичи может привести к непредвиденным изменениям во всей игре.

3. Постпродакшн

• Анализ эффективности идеи – смогла ли она достичь поставленных изначально целей или нет.

Таким образом, работа гейм-дизайнера глубоко вплетается в весь процесс разработки игры и серьезно влияет не только на то, что будет делаться в игре – какие механики, какой сеттинг, жанр и т. п., – но и на то, как игра будет разрабатываться, включая не только технологии, но и методики управления.

* * *

Дизайн-документация игры – это комплекс документов, который должен содержать исчерпывающую информацию обо всех игровых элементах. В этих элементах довольно легко запутаться, и спасает только то, что процесс разработки документации, как и всей игры, итеративен и последователен. При разработке документации мы идем от общего к частному и имеем возможность циклами уточнять и пополнять недостающую информацию.

В чистом виде в нашей игре, вероятно, будет только игровой процесс. По крайней мере, мы, скорее всего, будем думать об игре именно так.

Даже без особых подробностей о том, что это за процесс такой, в каком мире он происходит, мы понимаем, что нашу игру нужно как-то запустить. И вот у нас уже получается небольшая последовательность действий, некоторые из которых должна выполнить сама программа игры, а